Message-ID: <9992735.1075855885330.JavaMail.evans@thyme>
Date: Mon, 4 Dec 2000 05:27:00 -0800 (PST)
From: mary.solmonson@enron.com
To: sally.beck@enron.com
Subject: Deal Database
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-From: Mary Solmonson
X-To: Sally Beck
X-cc: 
X-bcc: 
X-Folder: \Sally_Beck_Dec2000\Notes Folders\Notes inbox
X-Origin: Beck-S
X-FileName: sbeck.nsf

This is the response I put together for Louise.



This may be better done in person.  If so, give me a call when you have time.

Here is my vision of the two worlds - Enron and Commodity Logic.



There are two basic alternatives:

If you see Commodity Logic as an independent venture, then we should build-in 
independence in our communication of deal data.  The "Transaction Store" does 
this.  Beth's DriveTrain project being led by John Simmons will provide 
this.  In this model, not every function/system currently performed will be 
supplanted by a Commodity Logic module.  Complete reliance on Commodity Logic 
to provide deal data needed for these systems would certainly complicate the 
integration as Commodity Logic may reside outside the firewall.   The 
systems/functions we don't think we'll outsource to Commodity Logic are: 
Trade Capture, Contracts, Valuation, Credit, and SAP functions.  
Additionally, we would like to see the development of more reporting support 
for the DPR, Operations Pricing Model, EnTelligence, and SAP Warehouse data; 
the implementation of a workflow, issue-tracking tool; and an Enron-branded 
site for Customer Information.   This vision was arrived at by asking the 
question: "What would you never consider outsourcing, either due to 
competitive advantage, control issues, or confidentiality?"
I started shopping this vision around last week and will continue to do so 
this week to get feedback for finalization.

If the two are really one and will be managed as one going forward, then 
certainly a single deal database could suffice.  In this case, there should 
not be separately managed IT functions as redundant development efforts may 
occur and we could focus the resources on the top priorities.  Right now, 
Commodity Logic is heavily dependent upon Beth's resources to provide the 
data from the legacy systems.  The work to do these data feeds competes with 
other priorities currently underway such as Unify Performance, Alberta Open 
Access for Power, etc.  I think it is important to note that we have two 
different requirements for deal data.  One - to support Commodity Logic 
functions - is transactional and near-realtime in nature.  The second - to 
support reporting functions is probably a batch end of day process.  The 
technical design of the two would be different to meet functional and 
performance requirements.  So, in a combined world, there would still 
probably be two sources of deal data, one present on our network as separate 
messages for each deal that transactional systems build a listener to 
subscribe to and  a second source in a warehouse for reporting.

Either alternative can be approached, however organizational alignment and 
priorities might be different.  Further, if the intent is to break Commodity 
Logic off into a separate entity, then the first alternative is preferred to 
maintain arms-length independence. 

Another alternative is to consider Operations and Commodity Logic as a 
combined entity that is separate from Enron that offers systems and 
back-office services to Enron and other industry players.  I think this may 
be what Sally is envisioning.  If this is where we are headed, then some of 
Beth's resources that are directly tied to support of Operations' systems 
should be combined with Commodity Logic resources so we can have a focus on 
coordinated priorities.  I believe this alternative has the same issues as 
the first in terms of what is outsourced, e.g. becomes part of Commodity 
Logic, and what remains proprietary and confidential to Enron.

Let me know your thoughts. 
